# VISTA Link AI 智能体业务与产品解决方案（基于项目多文档）
> 文档定位：产品、业务、设计共同评审用的业务与产品主文档。
编制日期：2026-08-22
业务闭环复核：2026-08-23（依据钉钉团队空间中的主 PRD、AI PRD、评审纪要及统计定义重新校正）
日本市场流程校正：2026-08-23（结合资料请求、物件登记、来场预约、初回接客、离场后追客和个人信息处理习惯校正）
需求基线：[主 PRD V0.248](https://alidocs.dingtalk.com/i/nodes/N7dx2rn0Jb66LrvBTZkMPZN4JMGjLRb3)、[AI 与智能体 PRD V1.6](https://alidocs.dingtalk.com/i/nodes/o14dA3GK8g66L4qdTEXye0e9J9ekBD76)配套技术文档：[《VISTA Link AI 智能体技术架构与实施方案》](./VISTA_Link_AI智能体技术架构与实施方案.md)说明：主 PRD 与 AI PRD 是现阶段唯一的正式需求边界；本项目其他文档用于补充场景、产品决策、页面设计、技术实现和未来路线，不能直接替代正式 PRD。   

---

## 0\. 阅读规则：四类状态不能混用

本文对每项能力使用以下状态。这里的“采用”，表示方案认为该方向合理，并不代表未经评审就已经成为正式需求。

| 标记 | 含义 | 能否直接开发 |
|------|------|------------------|
| **【正式 PRD】** | 主 PRD V0.248 或 AI PRD V1.6 已有明确对象、流程、权限或验收要求 | 可以进一步拆分设计与研发任务 |
| **【采用，需改 PRD】** | 项目其他文档已经给出较完整、且与产品方向一致的方案 | 必须先补充或修改 PRD，再进入开发排期 |
| **【实施设计】** | 不改变业务范围的架构、交互、可靠性或工程实现建议 | 可随正式需求进入技术设计，但需产研评审 |
| **【暂缓/不采用】** | 当前数据、边界或价值不足，或会使 Link 变成重型 CRM、交易系统 | 不进入本阶段范围 |

一条总原则：
> 正式 PRD 决定“做不做”；其他文档帮助回答“为什么做、怎么做、先做什么、做到什么程度”。   

---

## 1\. 综合结论

### 1.1 最终产品定位

建议将 VISTA Link 定义为：
> **面向日本新建公寓销售，以项目内容与客户专属页面为基础，以客户自主浏览和现场接待事实为上下文，以可确认的 AI 工作草稿和 SMS 行动为输出的轻量销售协同平台。**   

更简洁地说：
> **VISTA Link = 新建公寓专业内容层 \+ 客户连续服务工作区 \+ B 端 AI 助手 \+ 受控行动层。**   

它不需要复制一套完整 CRM，也不需要成为合同、贷款、房源销控或交易系统。它应守住五项核心资产：
1. 项目级客群标准方案、主题内容包、必讲项和风险边界；
2. 项目内容、素材、页面及版本关系；
3. 客户专属页面与每次访问的连续状态；
4. 带有内容上下文、来源和版本的行为事件；
5. 有依据、可修改、经确认并可追溯的 AI 工作结果。

### 1.2 经过钉钉资料复核的完整业务闭环

复核后需要先纠正一个概念：**VISTA Link 的主业务闭环不是“内容 → AI → SMS/预约 → 交易结果”的单线流程。** 正式 PRD 定义的是销售围绕页面、现场讲解、客户自主访问和再次推荐形成的连续服务；SMS、预约系统和交易系统是不同阶段接入的行动或权威结果支路。

钉钉中的主 PRD 与 AI PRD 合并后，共有七类销售工作：接待前准备、已有客户现场接待、临时客户现场接待、远程咨询与首次发送、到访后发送资料、根据访问继续推荐、购买申请与签约状态更新。完整关系如下。
```mermaid
flowchart TB
    subgraph ENTRY["一、三个真实业务入口"]
        E1["已有客户到访\n已预约或已建档"]
        E2["临时客户到访\n未预约或尚未建档"]
        E3["远程咨询\n电话、LINE、邮件或资料请求"]
    end

    subgraph PREP["二、客户与内容准备"]
        P0["项目客群方案库\n通用及主要客群、内容包、必讲与风险项"]
        P1["查找或创建客户并读取接点来源"] --> P2{"当前客户阶段？"}
        P2 -->|"反响/首次接触"| P3["选择客群标准方案；\n无法判断时使用通用方案"]
        P2 -->|"个体追客/商谈"| P4["读取明确反馈、有效自主访问、\n历史讲解和未解决问题"]
        P4 --> P5["AI准备个体跟进、\n后续页面或复访方案"]
        P3 --> P6["使用标准页面和内容顺序"]
        P5 --> P6["销售检查并确认个体方案"]
        P0 --> P3
        P0 --> P5
    end

    subgraph CONTACT["三、接待或首次沟通"]
        O1["已有客户现场讲解"]
        O2["临时讲解"] --> O3["结束后创建或选择客户，\n关联、纠错或标记无效记录"]
        R1["远程说明并取得客户访问地址"]
        O1 --> O4["销售确认客户真实反馈、\n条件变化和未解决问题"]
        O3 --> O4
    end

    subgraph FOLLOW["四、页面提供与客户自主访问"]
        F1["根据现场反馈或再次建议\n选择/制作后续页面并绑定客户"] --> F2{"实际发送通道"}
        F2 -->|"正式PRD当前做法"| F3["销售在LINE或邮件等外部工具发送"]
        F2 -->|"目标扩展"| F4["销售确认后由Link发送SMS"]
        F3 --> F5["客户打开地址并完成身份识别"]
        F4 --> F5
        F5 --> F6["客户自主浏览"]
        F6 --> F7["生成独立访问记录和历史内容快照"]
    end

    subgraph NEXT["五、再次推荐与下一轮服务"]
        N1["销售或AI按可靠事实整理\n询问方向和资料建议"] --> N2{"下一步决定"}
        N2 -->|"再次提供页面"| N3["准备新的页面或访问地址"]
        N2 -->|"再次到访"| N4["进入下一次接待准备"]
        N2 -->|"预约协调"| N5["外部预约或日历系统处理"]
    end

    subgraph RESULT["六、真实业务结果与状态"]
        X1["实际沟通、预约、到访、\n购买申请或合同结果"] --> X2["人员或权威系统确认事实"]
        X2 --> X3["销售确认后手动更新客户状态"]
        X3 --> X4{"继续跟进？"}
        X4 -->|"是"| X5["回到下一轮准备或推荐"]
        X4 -->|"否"| X6["签约或未签约"]
    end

    E1 --> P1
    E3 --> P1
    P6 --> O1
    P6 --> R1
    E2 --> O2
    O4 --> F1
    R1 --> F2
    F7 --> N1
    N3 --> F1
    N4 --> P2
    N5 --> X1
    X5 --> N1
    N2 -->|"发生明确业务结果"| X1
```

这张图中必须坚持四个分离：

| 需要分开的闭环 | 负责回答的问题 | 不能混入的内容 |
|---------------------|---------------------|---------------------|
| 内容底座闭环 | 页面和素材是否可用、已发布、版本正确 | 不能把草稿或过期资料当成可发送内容 |
| 销售服务闭环 | 本次从哪里开始、展示/发送了什么、客户之后做了什么、下一次如何继续 | 不能漏掉临时客户、远程咨询和再次推荐 |
| AI 工作闭环 | 读取什么依据、生成什么草稿、谁确认、写回什么 | AI 判断不能直接成为预约、到访或签约事实 |
| 外部结果闭环 | 预约、到访、购买申请和合同等真实结果来自哪里 | Link 不重复建设完整预约、贷款、合同和交易系统 |

相对上一版图，本次补回并纠正了以下节点：
1. 补回“已有客户、临时客户、远程咨询”三个业务入口；
2. 补回客户查找/创建、反响来源、首次客群方案选择，以及进入个体追客后的历史读取和个体页面准备；
3. 补回临时讲解结束后的客户关联、纠错和无效记录处理；
4. 补回“到访后重新整理并发送资料”，不是现场讲解结束后直接进入预约；
5. 补回客户身份识别、自主访问、独立访问记录和历史内容快照；
6. 补回“根据访问再次推荐”，形成页面与客户关系的循环；
7. 补回购买申请至签约/未签约的**状态回写**，但外部业务表单和合同仍不进入 Link；
8. 将 SMS 改为目标扩展通道，将预约与交易改为外部权威结果支路，不再把它们画成每个客户都必须经过的主链路。
9. 增加项目级客群方案库：反响和首次接触阶段直接使用客群标准方案；客户产生可靠个体事实并进入个体追客后，才生成个体跟进或复访方案。

### 1.3 功能边界结论

| 能力 | 综合决策 | 说明 |
|------|------------|------|
| 项目级客群标准方案与主题内容包 | 【采用，需改 PRD】 | 项目预先配置通用及主要客群方案、默认内容、必讲项和风险项；反响和首次接触使用标准方案，进入个体追客后才按个体制定方案 |
| 浏览器内 B 端 AI 助手 | 【正式 PRD】 | 读取当前项目与对象上下文，生成草稿，写入前确认 |
| 客户、素材、页面、访问、追踪、仪表盘等 Agent 能力 | 【正式 PRD】 | 以 AI PRD V1.6 的工具和权限为准 |
| 区分客户自主浏览与销售现场演示 | 【正式 PRD】 | 实施时必须确保不能把销售点击误判为客户兴趣 |
| 接待准备、内容摘要、接待后纪要草稿 | 【正式 PRD】 | 事实、判断、建议必须分层并可追溯 |
| SMS 单客发送和发送结果回流 | 【采用，需改 PRD】 | 推荐作为第一个行动扩展，先逐次人工确认 |
| 预约协调和预约结果确认 | 【采用，需改 PRD】 | Link 可协调；“已确认”必须来自权威预约系统或人员 |
| 分享记录、渠道和活动绑定 | 【采用，需改 PRD】 | 是后续归因、ROI 的数据基础 |
| 渠道归因 | 【采用，需改 PRD】 | 先首次/末次触达，保留全部原始触点 |
| ROI | 【采用，需改 PRD】 | 属于后置能力；成本、收入、归属范围和口径版本完整后再建设 |
| 自动意向评分 | 【采用，需改 PRD】 | 属于后置能力；先做解释型信号与规则，后做校准评分；不得黑箱化 |
| 完整销售任务系统 | 【暂缓/不采用】 | 只保留与内容、接待和行动相关的轻量待办或外部同步 |
| 完整预约、认购、签约和交易管理 | 【暂缓/不采用】 | Link 记录必要结果，流程由 CRM/预约/交易系统负责 |
| 独立 AI 审核中心 | 【暂缓/不采用】 | 审核能力保留，嵌入 AI 任务中心、客户详情和发送确认卡 |
| C 端开放式 AI 聊天 | 【暂缓/不采用】 | 当前只做 B 端，C 端展示确定、已发布、可控内容 |
| 任意数据库写入式 Agent | 【暂缓/不采用】 | 属于禁止性边界；Agent 只能调用有限、强类型、受权限与策略控制的工具 |

---

## 2\. 本方案采用了哪些项目文档

### 2.1 文档采用映射

| 来源文档 | 主要输入 | 本方案如何采用 | 状态处理 |
|------------|------------|---------------------|------------|
| [AI 原生产品定义与 SMS 行动平台方案](./VISTA_Link_AI原生产品定义与SMS行动平台方案_整合稿.md) | AI 原生四层架构、SMS 优先、首个行动 MVP、系统/AI/人员边界 | 作为产品定位、SMS 行动层和统一业务对象的主要来源 | SMS 等超出正式 PRD 的部分标记“需改 PRD” |
| [日本新建公寓销售场景下的 AI 后台助力方案](./VISTA_Link_日本新建公寓销售场景下的AI后台助力方案.md) | 接待连续性、客户条件、未解决问题、重复来访、证据优先级 | 作为日本业务场景、页面信息结构和 AI 介入时点的主要来源 | 独立审核中心不采用；改为嵌入式审核 |
| [AI 驱动产品设计与轻量化操作方案](./VISTA_Link_AI驱动产品设计与轻量化操作方案.md) | 三问工作台、3 次点击、模型网关、可解释/可纠正、风险分级 | 作为销售端交互原则、模型路由、证据结构和风险控制来源 | 与正式 PRD 冲突的自动发送/评分按扩展处理 |
| [四项薄弱能力提升方案](./VISTA_Link四项薄弱能力提升方案.md) | 跟进、归因、到访/交易结果、外部系统集成及建设依赖 | 作为分享记录、结果模型、统一接口层和实施顺序来源 | 完整任务/交易模块收缩为轻量记录或外部系统连接 |
| [功能切入与简化操作方案](./VISTA_Link功能切入与简化操作方案.md) | 功能嵌入现有页面、一个主要动作、最少输入 | 作为客户详情、分享页、任务确认卡的交互设计来源 | 不新增四套孤立一级菜单 |
| [AI 到场方案与 PRD 对照分析](./VISTA_Link_AI到场方案与PRD对照分析.md) | PRD 与延展的状态划分、Link 与 CRM/预约/交易边界 | 作为范围冲突裁决和 PRD 变更判断依据 | 用现行 V0.248/V1.6 替代历史版本号 |
| [产品整改任务书](./VISTA_Link产品整改任务书.md) | 数据隔离、深层链接、页面/素材版本、状态模型、审计等基础问题 | 作为 AI 上线前的数据可信度和产品基础门槛 | 基础问题未通过时不扩大自动执行 |
| [PRD 完整复核与重构调整建议](./VISTA_Link_PRD完整复核与重构调整建议.md) | 从分享、行为到行动和结果的服务流；基础口径问题 | 作为依赖关系、验收顺序和产品主线来源 | 讨论稿能力不直接视为正式需求 |
| [日本竞品影响与产品应对建议](./VISTA_Link_日本竞品影响与产品应对建议_2026.md) | KASIKA、ROOV、Digima、Facilo 等企业行为；Link 防守位置 | 作为差异化定位、接口战略和 12 个月优先级来源 | 不按竞品功能表盲目扩张 |
| [浏览器端多租户 AI 智能体详细解决方案](./VISTA_Link_浏览器端多租户AI智能体_详细解决方案.md) | 浏览器 Agent、多租户、任务、工具策略网关、队列、容量、可靠性 | 作为本方案的工程实施底座 | 本文补充业务与产品整合，不重复替代底层详细设计 |
| [跨项目继续工作交接摘要](./VISTA_Link_跨项目继续工作交接摘要.md) | 已确认方向、历史冲突、待决策项 | 用于防止历史讨论稿被误当成正式 PRD | 以最新 PRD 和本次综合判断为准 |

### 2.2 冲突内容如何处理

| 文档间冲突 | 处理决定 |
|---------------|------------|
| 有的文档建议建立独立“AI 审核中心”，AI PRD 当前不纳入独立审核中心 | 保留审核对象、风险分级和审计记录；入口嵌入 AI 任务中心、客户详情及操作确认卡 |
| 有的整改稿建议建设完整跟进任务、预约和交易模块，后续定位要求不做重型 CRM | Link 仅建设“与内容和接待直接相关的轻量行动/结果对象”；完整工作流连接外部系统 |
| 有的文档把高意向评分放在第二阶段，有的文档明确先不做黑箱评分 | 第一阶段只做事实信号、规则提示和接待准备；有真实结果后再做可解释评分 |
| 用户希望最终建设 ROI，但若先做会缺少成本与成交数据 | 产品方向保留，实施顺序后置到身份链、触点、成本、权威结果完整之后 |
| 主 PRD 出现浏览器 AI 入口，AI PRD 的历史首批范围曾不含内置 Web Agent | 使用功能开关和分阶段试点；以发布时双方更新后的统一版本为准 |

### 2.3 本次钉钉目录复核与直接来源

本次重新读取了团队空间中的 [VISTA Link 文件夹](https://alidocs.dingtalk.com/i/nodes/gwva2dxOW4ZZX6qPckRjZgMaJbkz3BRL)，并以团队正式文档优先、个人分析稿辅助解释。业务闭环的直接依据如下。

| 钉钉来源 | 本次采用的章节或结论 | 对闭环的影响 |
|------------|------------------------------|------------------|
| [VISTA Link 产品需求文档（最新版，V0.248）](https://alidocs.dingtalk.com/i/nodes/N7dx2rn0Jb66LrvBTZkMPZN4JMGjLRb3) | §1.7 总体流程、§2.2 销售人员工作流、§7.1.1 销售场景验收、§8.4 企业试用验收 | 确认现场接待、页面发送、客户自主访问、再次推荐和状态手动更新是正式主线 |
| [VISTA Link AI 与智能体产品需求文档（最新版，V1.6）](https://alidocs.dingtalk.com/i/nodes/o14dA3GK8g66L4qdTEXye0e9J9ekBD76) | §2.6 七类销售场景、§2.7 固定流程、§16.1 接待前准备、§16.8 讲解后准备页面 | 补齐接待前准备、临时客户、远程咨询、到访后发送、再次推荐及人工审核点 |
| [2026-07-30 VISTA Link B 端需求评审会议纪要](https://alidocs.dingtalk.com/i/nodes/Obva6QBXJw44Knv2cM5Pw3ym8n4qY5Pr) | §3.3 客户与分享关系、§3.5 页面与分享、§3.6 客户追踪 | 确认“复制链接不等于已发送”，客户识别和真实访问必须单独记录 |
| [VISTA Link B 端统计需求定义](https://alidocs.dingtalk.com/i/nodes/dpYLaezmVNAA9Dp2iK2q5E33WrMqPxX6) | 客户追踪、营销统计、现场讲解与自主访问的记录口径 | 确认现场讲解与客户自主访问不得合并统计 |
| [VISTA Link AI 原生产品定义与 SMS 行动平台方案（整合稿）](https://alidocs.dingtalk.com/i/nodes/mExel2BLV5aaKAqwupRyznZ4Vgk9rpMq) | §9 SMS 平台、§11 MVP、§12 路线、§14 PRD 调整 | 将 Link 原生 SMS 定义为目标扩展，但不反向改写当前正式 PRD 的外部发送边界 |
| [日本新建公寓销售场景 AI 方案（版本边界标注版）](https://alidocs.dingtalk.com/i/nodes/2Amq4vjg89RRDA9BsxGjvj0RW3kdP0wQ) | 来访准备、现场接待、多次来访、资金与申请准备 | 补充日本业务中的客户条件变化、未解决问题和多次来访连续性 |

复核时采用的优先级是：**正式主 PRD和正式 AI PRD ＞ 团队评审纪要与统计定义 ＞ 已标注版本边界的场景方案 ＞ 个人分析与后续产品提案。** 后续产品提案可以推动改 PRD，但不能悄悄替换当前正式边界。

---

## 3\. 日本新建公寓销售场景的核心问题

### 3.1 Link 需要解决的不是“更多数据”，而是服务连续性

日本新建公寓销售通常不是一次浏览、一次到访就完成。客户会经历线上了解、资料比较、预约、首次到访、家庭讨论、再次到访、资金与申请准备。问题往往不是没有资料，而是：
- 销售不知道客户已经自主看过什么；
- 现场又重复讲解客户已经知道的内容；
- 客户明确表达的预算、户型、时间等条件散落在问卷、浏览和人工记录中；
- 本次未回答的问题没有成为下一次接待准备；
- 第二次到访时无法快速理解客户条件发生了什么变化；
- 系统把销售现场点击误当成客户自主兴趣；
- 管理者看到访问量，却看不到接待是否准备充分、问题是否得到解决。

因此，AI 的第一价值不是“判断谁一定会买”，而是：
> **让本次接待更完整，让下一次接待能够从上次结束的位置继续。**   

### 3.2 日本当前市场习惯下的四阶段客户状态

日本新建公寓销售中，客户在资料请求、物件登记或来场预约后，通常已经进入企业的标准追客范围，但这并不等于已经形成个体商谈。三井、野村等开发商会在资料请求或线上咨询阶段收集预算、户型、面积、入住人数、当前居住形态、购房阶段和信息来源；另一方面，日本大型开发商也明确允许尚处于长期信息收集阶段的客户来场。因此，系统不能把“已经登记”直接解释成“高意向”或“可以生成个体方案”。

2025 年首都圈新建公寓购买者调查显示，购买动机与家庭结构已经更加多样，“资产持有”首次成为最主要购买动机，夫妻、育儿家庭、单身和老年夫妻均占有明显比例。因此，首次标准方案应按**本次接触目的和客户主动表达的关注主题**选择，不能只按年龄、家庭结构或 AI 推测建立固定人物标签。

建议将客户分为四个阶段：

| 阶段 | 日本销售现场对应 | 系统处理 | AI 边界 |
|------|------------------------|------------|---------|
| 反响阶段 | 资料请求、物件登记、来场预约、线上咨询申请 | 记录来源、客户主动填写条件、联系许可；选择客群标准方案并进行标准培育 | 不生成个体销售判断，不把登记或一次点击当成高意向 |
| 初次接触阶段 | 首次远程沟通、首次来场、临时来场 | 使用标准方案；现场可切换或追加主题包；记录实际展示和客户原话 | 可以整理记录，不替客户确认条件，不在接待前生成个体方案 |
| 个体追客阶段 | 初次沟通结束，销售确认存在明确下一步 | 结合明确表达、有效自主访问、历史讲解和未解决问题制定个体跟进/复访方案 | AI 可以生成个体草稿，但必须由销售确认、修改或驳回 |
| 申请及结果阶段 | 购买申请、贷款、认购、签约或未签约 | 只接收销售或权威外部系统确认的结果 | 不根据页面浏览、接待记录或评分推断业务结果 |

这里需要区分两个容易混用的概念：
- **标准追客/培育**：客户完成资料请求或登记后即可开始，使用项目批准的标准页面、通知、预约提醒和内容更新，不做个体推断；
- **个体追客/商谈化**：客户完成首次沟通，产生可靠个体事实并存在明确下一步后才开始，允许 AI 准备客户专属跟进方案。

仅有页面浏览次数增加时，系统最多提示销售复核，不能自动把客户升级为个体追客。

市场与合规依据：
- [三井不动产住宅资料请求表](https://www.31sumai.com/entry/G2004/?ENT=1)：资料请求阶段即收集预算、面积、户型、居住和渠道信息；
- [野村不动产在线咨询登记](https://www.proud-web.jp/module/oubo/input?formID=3309)与[住宅购买问答](https://www.proud-web.jp/guide/faq.html)：区分信息收集、具体物件比较和来场/线上咨询，不把所有来场者视为近期购买；
- [SUUMO 2025 年首都圈新建公寓契约者调查](https://suumo-research.com/work/resident-insights/resident-insights-1907/)：购买动机和家庭结构持续多样化；
- [STYLE PORT 2025 年新建公寓销售 DX 数据](https://styleport.co.jp/news/6163/)与[ROOV 新建公寓方案](https://styleport.co.jp/roov/for-mansion/)：离场后自主浏览和行为记录已成为线上线下融合销售的重要组成；
- [KASIKA 新建公寓方案](https://cocolive.co.jp/mansion/)：按资料请求者、来场者及打开/点击行为进行标准培育和销售跟进；
- [日本个人信息保护委员会通则指南](https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/)：通过表单或问卷直接取得个人信息时，应在客户可识别的位置明确利用目的。

### 3.3 日本场景的推荐服务流
```mermaid
flowchart TB
    A{"客户从哪里进入？"}
    A -->|"远程咨询/已有客户"| B1["查找或创建客户"]
    A -->|"临时客户到访"| B2["使用通用客群方案开始临时讲解"]
    B1 --> C{"当前客户阶段？"}
    C -->|"反响/首次接触"| D["选择客群标准方案；\n无法判断时使用通用方案"]
    C -->|"个体追客：已有可靠事实"| E["AI生成个体跟进、\n后续页面或复访方案"]
    D --> F{"远程还是现场？"}
    E --> F
    F -->|"远程"| G["取得客户访问地址"]
    F -->|"现场"| H["现场接待与内容演示"]
    B2 --> I["结束后关联客户"]
    I --> J["销售确认客户反馈"]
    H --> J
    J --> K["纪要、条件变化和未解决问题草稿"]
    K --> L["销售确认事实与下一步，\n客户进入/更新个体追客"]
    L --> M["准备个体后续页面、消息或复访方案"]
    G --> N{"发送方式"}
    M --> N
    N -->|"当前正式范围"| N1["销售在外部LINE/邮件等工具发送"]
    N -->|"目标扩展"| N2["Link确认后发送SMS"]
    N1 --> O["客户身份识别与自主浏览"]
    N2 --> O
    O --> P["记录访问内容、次数、时长和明确动作"]
    P --> Q["更新个体跟进方案"]
    Q --> R{"继续方式"}
    R -->|"再次发送"| M
    R -->|"再次来访"| E
    R -->|"进入购买申请/合同"| S["外部业务完成，销售手动回写状态"]
```

这一服务流不要求每个客户都先预约，也不要求每个客户都进入 SMS。预约可以是已有客户来访的来源之一，也可以是再次推荐后的外部动作；SMS只是页面提供的一种目标通道。**真正不可缺少的是“本次接触—客户之后的自主行为—下一次销售准备”能够连续衔接。**

### 3.4 AI 只在三个时点主动介入
1. **客户进入个体追客后**：客户已经产生明确反馈、有效自主浏览或历史接待记录，并由销售确认存在下一步时，才按个体生成跟进/复访方案；
2. **接待后**：对比客群标准方案与现场实际情况，生成待确认纪要、未解决问题和后续页面/SMS 草稿；
3. **追踪信息变化时**：发现资料版本更新、客户条件变化、结论过期或事实冲突。

首次咨询和首次接待直接使用预先制作的客群标准方案，不要求 AI 在接待前为单个客户重新生成一套方案。其他能够通过一次查询、一次勾选或固定规则完成的工作，也不调用模型。

### 3.5 房地产销售应采用“客群标准方案—现场适配—个体追客后个性化”

售楼接待具有较强的重复结构。项目概况、交通、户型、样板间、眺望、日照、公共设施、价格费用和购买流程等基础内容，应在项目上线时就按主要客群做好标准方案。首次咨询或首次接待直接使用对应客群方案，**不需要在接待前再为单个客户生成一套方案**。

客户完成资料请求或登记后，可以进入标准追客/培育；只有完成首次接触、产生明确表达、有效自主浏览、现场讲解或后续业务结果，并由销售确认进入个体追客后，系统才基于个体事实制定后续页面、沟通和复访方案。

#### 3.5.1 建议预先建立的客群方案

每个项目可以根据实际客群选择 4—6 类，不要求全国或所有项目使用同一套。第一版建议从以下需求导向的客群中选择：

| 客群标准方案 | 默认关注重点 | 默认内容包 |
|------------------|------------------|---------------|
| 通用/尚未判断 | 建立项目基础认知 | 项目概览、位置交通、代表户型、样板间/VR、公共设施和费用基础 |
| 通勤便利型 | 车站、线路、工作地通勤和生活便利 | 区位交通、地图、周边生活、代表户型和来访入口 |
| 家庭空间型 | 房间数量、面积、收纳、育儿和长期居住 | 户型比较、室内空间、公共设施、周边环境和生活动线 |
| 预算费用型 | 总价、月度支出、管理费、修缮费和资金安排 | 价格费用、户型价差、费用说明和可使用的官方资金资料 |
| 居住品质型 | 眺望、日照、朝向、设计、设备和公共空间 | 眺望日照、样板间、设备规格、共用部和设计说明 |
| 资产配置型 | 区位价值、出租、转售和长期持有 | 区位、供需、户型流通性及经批准的资产说明；不得由 AI 承诺收益 |

客群方案不是客户的永久标签。首次接触时只是选择一套合适的标准介绍路径；如果无法判断，直接使用“通用/尚未判断”，不强行归类。

#### 3.5.2 每套客群方案预先包含什么

| 配置内容 | 说明 |
|------------|------|
| 默认内容和顺序 | 该客群通常先看什么、后看什么 |
| 标准页面/素材包 | 已发布且当前有效的项目页面、Widget 和素材 |
| 标准提问 | 用于确认客户是否确实属于该需求方向，不把推测写成事实 |
| 必讲项 | 当前项目要求必须说明的费用、限制、交付或其他事项 |
| 风险边界 | 价格、折扣、贷款、收益、交付和合同等不得自由承诺的内容 |
| 切换规则 | 客户现场关注方向明显变化时，可以切换到另一客群方案或追加一个主题包 |

#### 3.5.3 正确业务流程
```mermaid
flowchart LR
    A["项目预先配置\n客群标准方案、内容包、必讲与风险项"] --> B["首次咨询或首次到访"]
    B --> C{"选择客群方案"}
    C -->|"可以判断"| D["直接使用对应客群标准方案"]
    C -->|"暂时无法判断"| E["使用通用方案"]
    D --> F["现场或远程沟通"]
    E --> F
    F --> G["按客户真实反应切换方案、追加或跳过内容"]
    G --> H["记录实际展示、客户明确表达和未解决问题"]
    H --> I["客户离场/首次沟通结束"]
    I --> J{"销售是否确认\n存在明确下一步？"}
    J -->|"否"| J1["继续标准追客/培育"]
    J1 --> H
    J -->|"是"| K["进入个体追客，结合明确反馈、\n有效访问和历史记录"]
    K --> L["AI生成个体跟进、后续页面或复访方案"]
    L --> M["销售确认并执行"]
    M --> N["新的行为和业务结果回流"]
    N --> K
```

三个阶段的责任是：
- **首次接触前**：项目团队提前把客群标准方案做好，销售只选择方案，不为单个客户做 AI 定制；
- **首次接触中**：销售根据现场或远程沟通实时切换、追加或跳过内容，系统只记录实际发生的事实；
- **离场后**：销售先确认客户原话、条件变化、未解决问题和是否存在明确下一步；未商谈化的客户继续标准培育；进入个体追客后，AI 才根据可靠事实生成个体跟进、后续页面和复访方案。

#### 3.5.4 首期保持简单

第一版不要建设复杂的多级客群树。每个项目只需要：
1. 配置一个通用方案和 4—5 个主要客群方案；
2. 每套方案维护默认内容顺序、标准提问、必讲项和风险边界；
3. 首次接触只选择一个客群方案，必要时现场追加一个主题包；
4. 客群选择只是本次接待路径，不自动写成已确认客户属性；
5. 没有足够信息时使用通用方案，不要求销售猜测客户类型；
6. 资料请求或登记客户可以接受标准培育；客户产生明确反馈或有效行为，并由销售确认进入个体追客后，才创建个体方案；
7. 个体方案不自动修改项目客群模板；只有多个客户反复出现同类变化时，才提示管理者评估模板更新。

---

## 4\. 用户角色与核心任务

| 角色 | 核心任务 | AI 提供的帮助 | 不能替代的责任 |
|------|------------|------------------|---------------------|
| 一线销售/接待人员 | 准备接待、现场说明、跟进客户 | 客户摘要、接待卡、内容组合、日文 SMS 草稿、问题清单 | 确认客户表达、发送对外内容、作出业务承诺 |
| 销售经理 | 查看异常、待确认、高风险内容与服务质量 | 汇总未解决问题、超期事项、团队数据质量 | 审核高风险内容、处理例外和权限 |
| 内容运营 | 管理项目资料、素材、页面和版本 | 检查缺失/过期/引用影响，生成页面草稿 | 确认发布内容、价格政策和生效版本 |
| 项目管理员 | 管理成员、权限、渠道、连接器和模型策略 | 生成配置建议、同步异常摘要 | 配置权限、密钥、额度和外部主数据源 |
| 外部智能体 | 在授权范围内读取或调用 Link 工具 | 跨系统理解与编排 | 不得绕过 Link 权限、确认和审计 |
| 客户 | 浏览已发布页面、接收确认后的消息 | 当前不直接使用开放式 AI | 决定是否回复、预约和继续了解 |

---

## 5\. 产品形态：浏览器内的 B 端智能体

### 5.1 全局入口

【正式 PRD】在主系统右下角提供 AI 入口。打开后默认获得：
- 当前租户；
- 当前项目；
- 当前页面或对象类型；
- 当前对象 ID；
- 当前用户与实时权限；
- 用户主动选中的客户、素材、页面或访问记录。

AI 不应默认读取整个租户数据，更不能把其他项目数据带入当前回答。

### 5.2 侧边面板结构
```mermaid
flowchart TB
    A["AI助手侧边面板"] --> B["当前范围<br/>项目 / 客户 / 页面 / 素材"]
    A --> C["对话与任务输入"]
    C --> D["结论卡<br/>AI整理结果"]
    D --> E["依据卡<br/>系统事实 / 资料版本 / 原始记录"]
    D --> F["草稿区<br/>页面 / 摘要 / 接待卡 / SMS"]
    F --> G["变更对比<br/>现有版本 vs 准备写入"]
    G --> H{"风险级别"}
    H -->|低风险| I["保存内部草稿"]
    H -->|需要确认| J["销售确认"]
    H -->|高风险| K["负责人审核"]
    I --> L["任务与审计记录"]
    J --> L
    K --> L
```

### 5.3 三层结果展示

每个重要输出固定使用三层结构：
1. **结论**：用户现在最需要知道或处理什么；
2. **依据**：时间、次数、来源、客户原话、资料版本和置信度；
3. **原始记录**：可以跳到对应访问、页面、问卷、现场记录或资料原文。

示例：
```text
【系统事实】
客户 7 天内自主访问 3 次，重复查看 A 户型和费用页面。

【AI 判断】
客户可能仍在比较月度支出，置信度 82%。

【AI 建议】
发送最新费用说明，并在下次接待中确认预算范围。

[查看 3 条访问记录] [查看费用资料 V2026.08] [纠正判断]
```

### 5.4 AI 任务中心，而非独立审核中心

任务中心统一承载：
- 正在运行；
- 等待用户补充；
- 等待销售确认；
- 等待负责人审核；
- 执行中；
- 已完成；
- 失败或需要重试；
- 已取消。

审核只是任务状态和风险处理方式，不再新建一套与客户、内容、发送完全分离的一级导航。

---

## 6\. 页面与信息结构方案

### 6.1 项目总览

首页不堆放大量统计卡片，优先回答：
1. 今天需要准备哪些接待？
2. 反响/首次接触采用哪个客群标准方案，哪些个体追客客户已经生成个体方案？
3. 哪些 AI 草稿或对外内容等待确认？
4. 哪些客户存在未解决问题、资料过期或数据冲突？

推荐区域：

| 区域 | 内容 | 主要动作 |
|------|------|------------|
| 反响/首次接触方案 | 反响来源、联系许可、客群标准方案、默认内容、标准提问、必讲项和风险项 | 选择/切换方案 |
| 个体追客方案 | 客户、历史反馈、已看内容、未解决问题和个体跟进/复访方案 | 查看并确认 |
| 客群方案维护 | 通用及主要客群的内容包、必讲项、风险项和版本 | 预览/维护 |
| 待确认 | 页面草稿、纪要、SMS、高风险回复 | 检查并确认 |
| 需要补齐 | 缺少负责人、来源、有效资料或权威结果 | 指派/补齐 |
| 未解决问题 | 客户问题、责任人、期限、是否需专业人员 | 查看并处理 |
| 数据质量 | 身份未关联、外部/现场来源不明、资料版本冲突 | 修正来源 |

### 6.2 客户列表

默认按“需要处理”而不是按创建时间排序，显示：
- 当前销售/接待阶段；
- 最近关键事实；
- 是否有待确认信息；
- 是否有未解决问题；
- 下一次来访或建议处理时间；
- 资料/判断是否已过期；
- 当前负责人。

### 6.3 客户详情：统一工作区
```mermaid
flowchart TB
    A["客户详情统一工作区"]
    A --> B["当前状态层"]
    A --> C["AI协同层"]
    A --> D["事实与历史层"]
    A --> E["行动层"]

    B --> B1["当前客户条件"]
    B --> B2["来源 / 日期 / 确认状态"]
    B --> B3["历史变化与冲突"]

    C --> C1["接待准备卡"]
    C --> C2["纪要草稿"]
    C --> C3["未解决问题"]
    C --> C4["反响/首次客群方案、现场变化与个体追客方案"]

    D --> D1["自主浏览"]
    D --> D2["现场演示"]
    D --> D3["问卷与客户表达"]
    D --> D4["分享、消息和权威结果"]

    E --> E1["推荐下一步"]
    E --> E2["检查并发送"]
    E --> E3["确认预约结果"]
    E --> E4["统一时间线与审计"]
```

每个阶段只突出一个主要按钮：
- 接待前：“查看接待准备”；
- 接待后：“确认本次纪要”；
- 有补充内容：“检查并发送”；
- 有预约意向：“确认预约结果”；
- 有数据冲突：“核实事实”。

### 6.4 内容与页面库

除原有项目、分类、标签、状态和版本外，建议补充：
- 适用销售阶段；
- 适用客户条件；
- 所属标准主题内容包和默认展示顺序；
- 是否为客群标准方案必讲项、可选项或禁止自动推荐项；
- 外部分享/现场演示适用范围；
- 资料版本与生效时间；
- 是否涉及价格、优惠、交付或合同等高风险信息；
- 引用该素材的已发布页面；
- 更新后受影响页面和客户。

AI 只能向外推荐已发布且当前有效的内容；内部草稿必须明确标识，不得自动发送。

### 6.5 行为时间线

每个事件必须标明来源：

| 来源类型 | 示例 | 能否直接解释为客户兴趣 |
|------------|------|---------------------------------|
| 客户自主行为 | 客户通过专属链接浏览、比较、下载 | 可以作为行为证据，但不能单独等于购买意向 |
| 员工现场演示 | 销售在接待现场打开户型、费用资料 | 不能自动解释为客户兴趣 |
| 客户明确表达 | 问卷、经销售确认的客户原话 | 高优先级证据 |
| 系统事件 | 页面发布、素材更新、消息送达、同步完成 | 仅表示系统状态 |
| 外部权威结果 | 预约系统确认、CRM 到访、交易系统结果 | 作为业务事实 |

---

## 7\. 证据、事实和推断模型

### 7.1 三类信息必须分开保存

| 类型 | 示例 | 责任 |
|------|------|------|
| 系统事实 | 某时访问某页面；SMS 已送达；预约系统返回已确认 | 系统或权威外部系统 |
| 客户表达 | “预算约 6,000 万日元”“希望 3LDK” | 客户表达；AI 可提取，但需人员确认 |
| AI 推断 | “可能关注月供”“本次应重点说明交通” | AI 生成；显示依据、置信度、版本和失效时间 |

### 7.2 证据优先级
```text
客户明确条件
    > 现场经员工确认的反馈
    > 客户自主浏览行为组合
    > 销售现场演示点击
```

当证据冲突时，不允许 AI 静默覆盖。系统应展示：
- 哪两条信息发生冲突；
- 各自来源与时间；
- 哪条是当前有效事实；
- 是否需要销售在下次接待中确认。

### 7.3 AI 结论最少字段

| 字段 | 说明 |
|------|------|
| conclusion\_type | 摘要、条件、变化、风险、行动建议等 |
| conclusion | 结构化结论 |
| confidence | 置信度；低风险摘要也要能说明不确定性 |
| evidence\_ids | 对应访问、问卷、资料、现场记录或外部结果 ID |
| source\_versions | 使用的页面、素材、政策或规则版本 |
| model*strategy*version | 模型、提示模板、规则与路由版本 |
| generated*at / expires*at | 生成与失效时间 |
| user\_decision | 未处理、确认、修改、驳回 |
| corrected\_value | 人工修正结果 |
| tenant*id / project*id | 强制租户和项目范围 |

---

## 8\. 七个正式销售流程、两个扩展流程与治理流程

本节按钉钉正式 AI PRD §2.6 的七类销售场景重新组织。前七项属于正式业务主线；SMS 和预约连接是目标扩展；管理者复核是治理流程，不是客户必须经过的业务节点。

| 编号 | 场景 | 当前状态 | 闭环中的作用 |
|------|------|------------|------------------|
| A0 | 反响/首次接触标准方案 | 【采用，需改 PRD】 | 项目预先维护客群标准方案；资料请求、登记和首次接触使用标准方案，无法判断时使用通用方案 |
| A | 个体追客客户准备 | 【正式 PRD】 | 完成首次沟通并由销售确认存在明确下一步后，才将可靠事实变成个体方案 |
| B | 已有客户现场接待 | 【正式 PRD】 | 记录真实讲解并承接客户反馈 |
| C | 临时客户现场接待 | 【正式 PRD】 | 允许先接待、后识别和关联客户 |
| D | 远程咨询与首次发送 | 【正式 PRD】 | 覆盖未到访客户的首次页面提供 |
| E | 到访后发送资料 | 【正式 PRD】 | 把现场反馈转为客户回家后继续看的内容 |
| F | 根据访问继续推荐 | 【正式 PRD】 | 把自主访问变成下一次询问或内容准备 |
| G | 购买申请与签约 | 【正式 PRD】 | 只依据外部明确结果手动更新客户状态 |
| H | Link 原生 SMS | 【采用，需改 PRD】 | 将一个外部发送通道升级为可审计的系统行动 |
| I | 预约系统连接 | 【采用，需改 PRD】 | 连接预约意向与权威确认，不建设完整预约系统 |

### 8.1 流程 A0/A：反响和首次接触使用标准方案，商谈化后进行个体准备

**触发条件**
- 资料请求、物件登记、来场预约、首次咨询、首次来访或临时到访：进入反响或初次接触阶段，选择客群标准方案并允许标准培育；
- 客户完成首次接触，产生明确反馈、有效自主浏览、未解决问题或再次到访等可靠事实，并由销售确认存在明确下一步：进入个体追客，可以生成个体方案；
- 购买申请、贷款、认购和合同等结果：进入申请及结果阶段，只接收人员或权威外部系统确认的事实。

**系统步骤**
1. 确认当前项目、客户身份、用户权限、反响来源、通信许可和个人信息利用目的；
2. 判断客户处于反响、初次接触、个体追客还是申请及结果阶段；
3. **反响阶段**：读取客户在资料请求、物件登记、来场预约或线上咨询中主动填写的预算、户型、面积、购房目的、入住人数、考虑时间和信息来源；
4. 根据本次接触目的和客户主动表达的关注主题选择客群标准方案；无法判断时使用通用方案，不生成个体销售判断；
5. **初次接触阶段**：销售按照标准方案接待，现场可以切换方案或追加主题包；系统记录实际展示、客户原话、明确问题和未解决事项；
6. 客户离场或首次沟通结束后，由销售确认客户表达、条件变化、下一步意愿和是否进入个体追客；
7. 没有明确下一步时，继续使用项目批准的标准页面、通知、预约提醒和内容更新进行标准培育，不生成个体方案；
8. **个体追客阶段**：分开读取客户明确表达、有效现场讲解、客户自主访问、历史变化和外部结果；
9. 按时间和来源整理，不把客群选择、现场展示或一次页面点击写成客户已确认属性；
10. AI 以客群标准方案为参考，生成该客户的跟进、后续页面或复访方案；
11. 销售确认、修改或驳回个体方案；
12. 保存客户阶段、反响来源、通信许可、使用的客群方案版本、个体依据、确认版本和实际执行结果。

**反响/首次接触卡**显示：反响来源、本次类型、客户主动填写的已知条件、通信许可、客群标准方案、默认内容顺序、标准提问、必讲项、风险项、预约信息和尚未确认内容。它不显示 AI 推测的家庭情况、购买能力或成交概率。

**个体追客准备卡**显示：已确认条件、条件历史、当前考虑阶段、客户已自主了解内容、销售实际讲解内容、未解决问题、客户主动说明的比较物件与决策参与者、资金准备状态、建议的下一份页面/复访内容、联系渠道与时间、个体建议及证据。

仅有页面浏览次数增加时，系统可以生成“建议销售复核”的事实提示，但不得自动进入个体追客、自动修改客户阶段或直接触发高风险对外动作。

### 8.2 流程 B：已有客户现场接待
1. 销售从已有客户详情选择已发布页面并开始现场讲解；
2. 系统建立独立讲解会话，记录讲解人、客户、页面版本、展示内容、次数和可靠时长；
3. 首次接待从客群标准方案开始；复访客户可以从已确认的个体复访方案开始；
4. 销售按客户实时反馈快速跳过、追加、替换内容或调整顺序，系统保存标准/个体方案与现场实际展示的差异；
5. 涉及价格、优惠、交付、贷款或合同的信息，只引用当前有效的已发布资料；
6. 无法现场回答的问题进入未解决问题；
7. 销售结束讲解，并按实际沟通决定是否手动更新客户状态、备注或标签。

讲解记录不增加客户自主访问次数，不触发客户首次打开通知，也不能自动形成兴趣评分。

### 8.3 流程 C：临时客户现场接待
1. 销售可从页面详情开始“临时讲解”，不要求先建客户；
2. 默认使用通用客群方案；如果现场方向明确，可以切换到其他客群标准方案；
3. 讲解期间只保存现场展示事实，不创建匿名客户访问；
4. 结束后记录显示“未关联客户”；
5. 销售可以创建新客户或选择已有客户并完成关联；
6. 关联错误时，销售选择正确客户、填写理由并保留修改前后记录；
7. 误开始且不代表真实讲解时，经二次确认和填写理由后标记为无效；
8. 关联完成并产生可靠反馈后，由销售确认是否进入个体追客；确认后再生成个体后续方案。

这一分支是上一版闭环图漏掉的重要入口。没有它，系统会要求销售在客户身份尚不明确时先建档，反而增加现场负担，并容易产生错误客户数据。

### 8.4 流程 D：远程咨询与首次发送
1. 客户通过电话、LINE、邮件或资料请求表达需求；
2. 销售查找或创建客户，根据本次咨询方向选择一个客群标准方案；无法判断时使用通用方案；
3. 直接使用该客群已经准备好的已发布页面和内容包，不在首次发送前为单个客户重新生成完整方案；
4. 沟通中方向发生变化时，销售可以切换客群方案或追加一个主题包；
5. 销售指定客户，取得带客户识别关系的访问地址；
6. 当前正式 PRD 下，销售在 Link 外部实际发送；目标扩展下可进入 §8.8 的 SMS 确认发送；
7. 地址复制、二维码展示或页面与客户建立关系，都不能写成“已经发送”；
8. 客户尚未真正打开前，不产生客户访问记录；
9. 客户回复或打开后只形成可靠行为事实；由销售确认存在明确下一步并进入个体追客后，才由 AI 制定个体页面和跟进方案。

### 8.5 流程 E：到访后发送资料
1. 系统读取本次使用的客群标准方案或个体复访方案、本次有效讲解记录和现场调整，列出原计划与实际展示的差异；
2. 讲解事实、现场调整与销售补充的客户反馈分开显示；
3. AI 根据差异生成结构化纪要草稿，分为已确认事实、客户表达和待确认提取；
4. 销售确认条件变化、顾虑、未解决问题及是否更新客户状态；
5. 系统只使用销售确认后的客户反馈作为后续选材条件；
6. 查找已有页面或生成新的页面工作草稿；
7. 销售检查、保存并确认发布；
8. 取得客户访问地址，并通过外部通道或 Link SMS 发送；
9. 发送的页面版本、客户、渠道和时间必须可追溯；
10. 将销售确认后的条件变化、未解决问题和后续重点写入该客户的个体跟进/复访方案，不直接覆盖项目客群标准方案。

### 8.6 流程 F：根据客户自主访问继续推荐
1. 客户打开访问地址，完成客户标识参数、访问会话或邮箱验证码识别；
2. 系统生成一次客户自主访问记录和访问内容快照；
3. 按访问数据状态排除机器人、内部测试、重复或异常记录；
4. 汇总页面、内容、次数、有效时长和 C 端已经定义的明确动作；
5. 检查客户当时看到的历史内容当前是否仍可用；
6. AI 给出带依据的询问方向和资料建议，不直接生成客户状态或确定购买意向；
7. 销售采用、修改或忽略建议；
8. 需要时选择已有页面或生成下一份页面工作草稿，再次提供访问地址；
9. 新访问形成新记录，不能改写旧页面版本、旧讲解或旧访问明细。

该流程形成 VISTA Link 真正的循环：**提供内容 → 客户自主访问 → 理解可靠行为 → 再次准备内容或接待。**

### 8.7 流程 G：购买申请至签约/未签约状态回写
1. 客户通过实际沟通确认准备购买后，购买申请、资金确认、贷款预审、重要事项说明和合同仍在外部业务中完成；
2. 系统只接收销售明确提供或权威系统回传的业务结果；
3. Link 展示客户原状态、目标状态、结果来源和更新时间；
4. 销售确认后，从当前项目未停用的状态中手动选择目标状态；
5. 完成买卖合同后可改为系统预置“签约”；未完成或客户放弃时可改为“未签约”；
6. 保存原状态、新状态、操作人、时间和外部依据引用；
7. 没有明确结果时不修改，页面访问、讲解记录和 AI 评分均不能作为签约依据。

这里的闭环是**状态回写和历史追溯**，不是在 Link 内执行购买申请、贷款或合同流程。

### 8.8 扩展流程 H：Link 原生 SMS 行动闭环

【采用，需改 PRD】SMS 是页面提供与跟进动作中的一个通道，不替代前述七类销售场景。
```mermaid
flowchart LR
    A["已确认的客户反馈或可靠访问事实"] --> B["AI准备日文SMS与客户专属页面"]
    B --> C["资料版本、同意、退订、频率和风险校验"]
    C --> D["销售查看依据、编辑并逐次确认"]
    D --> E["Link发送服务"]
    E --> F["SMS供应商"]
    F --> G["受理、送达、失败或退订回执"]
    G --> H["短链点击、客户识别和页面访问"]
    H --> I["事实写回客户时间线"]
    I --> J["进入再次推荐或接待准备"]
```

首期只支持单客户、单消息、逐次确认；必须绑定客户、页面版本、确认人、发送者和幂等键。首期不支持无限群发、未经确认的任意自动发送、高风险业务承诺，也不能把“提交给供应商”显示为“已送达”。

### 8.9 扩展流程 I：预约协调和权威结果连接

【采用，需改 PRD】预约意向不是预约成功，预约成功也不是实际到访。推荐状态机：
```mermaid
stateDiagram-v2
    [*] --> IntentDetected: 点击预约或销售确认意向
    state "预约意向" as IntentDetected
    state "建议可用时段" as SlotProposed
    state "临时时段占用" as SlotHeld
    state "等待权威确认" as PendingConfirmation
    state "预约已确认" as Confirmed
    state "预约被拒绝" as Rejected
    state "时段已过期" as Expired
    state "预约已取消" as Cancelled
    state "实际到访" as Visited
    state "未到访" as NoShow

    IntentDetected --> SlotProposed
    SlotProposed --> SlotHeld: 客户选择时段
    SlotHeld --> PendingConfirmation: 提交预约系统
    PendingConfirmation --> Confirmed: 权威系统写入成功
    PendingConfirmation --> Rejected: 冲突或不接受
    SlotHeld --> Expired: 暂占超时
    Confirmed --> Cancelled: 客户或销售取消
    Confirmed --> Visited: 人员或权威系统确认
    Confirmed --> NoShow: 人员或权威系统确认
    Rejected --> SlotProposed
    Expired --> SlotProposed
    Visited --> [*]
    NoShow --> [*]
    Cancelled --> [*]
```

Agent 可以查询可用时段、提出建议和发起暂占；只有预约/日历系统写入成功，Link 才显示“预约已确认”。确认到访后回到 §8.1 接待准备，而不是把预约流程作为业务终点。

### 8.10 治理流程：管理者复核

管理者不需要逐条审核所有 AI 摘要，只处理：
- 涉及价格、优惠、合同、交付等高风险对外内容；
- 批量发送或自动规则变更；
- 多次被纠正的 AI 结论；
- 数据来源冲突或资料过期；
- 发送失败、同步失败和权限异常；
- 临时讲解长期未关联、错误客户关联或无效记录；
- 长时间未解决的客户问题。

---

## 9\. 风险分级与人工控制

| 级别 | 示例 | 默认控制 |
|------|------|------------|
| R0 只读 | 查询项目、客户、页面、访问事实 | 直接执行，记录查询审计 |
| R1 内部草稿 | 摘要、接待卡、标签建议、纪要草稿 | 自动生成，可纠正，不写关键事实 |
| R2 普通写入 | 保存草稿、更新内部待确认字段 | 展示变更对比后由用户确认 |
| R3 对外动作 | 发布页面、发送单客户 SMS、发起预约暂占 | 逐次确认；成熟后可使用预授权规则 |
| R4 高风险动作 | 价格/优惠/合同/交付承诺、批量发送、关键策略修改 | 负责人审核；不得由普通销售自动执行 |
| R5 权威业务事实 | 已到访、已认购、已签约、金额 | 仅权威系统或有权限人员写入；AI 不得推断 |
```mermaid
flowchart LR
    A["AI结论或动作请求"] --> B["策略网关<br/>权限 / 项目 / 对象 / 版本"]
    B --> C{"风险等级"}
    C -->|R0 只读| D["直接执行并记录"]
    C -->|R1 内部草稿| E["自动生成，可纠正"]
    C -->|R2 普通写入| F["用户查看变更后确认"]
    C -->|R3 对外动作| G{"是否命中有效预授权"}
    G -->|否| H["销售逐次确认"]
    G -->|是| I["规则内执行"]
    C -->|R4 高风险| J["负责人审核"]
    C -->|R5 权威事实| K["权威系统或授权人员写入"]
    D --> L["Link业务服务"]
    E --> M["保存内部草稿"]
    F --> L
    H --> L
    I --> L
    J --> L
    K --> N["业务事实记录"]
    L --> O["结果与审计"]
    M --> O
    N --> O
```

预授权自动化必须明确：
- 适用租户、项目、角色和客户范围；
- 可使用的内容模板和版本；
- 可使用的渠道；
- 频率、时间段和金额/数量阈值；
- 有效期；
- 取消和人工接管方式；
- 每次命中规则的审计记录。

---

## 10\. 分享记录、渠道归因、ROI 与意向评分

### 10.1 分享记录是数据起点

【采用，需改 PRD】每次实际分享建立独立记录，而不是只依赖固定链接。

| 字段 | 说明 |
|------|------|
| share\_id | 随机、不可枚举的分享记录 ID |
| tenant*id / project*id | 租户与项目 |
| customer\_id | 目标客户，可为空但应标明匿名 |
| page*id / page*version | 分享页面及版本 |
| member\_id | 分享人 |
| channel / campaign\_id | LINE、SMS、邮件、二维码、活动等 |
| created\_at | 生成分享记录的时间 |
| copied*at / sent*at | 复制和实际发送是不同事件 |
| first*open*at | 首次打开时间 |
| parent*share*id | 需要时记录转发关系 |

所有参数使用内部映射或签名 Token，不在 URL 中直接暴露客户和业务敏感信息。

### 10.2 统一事件链
```mermaid
flowchart LR
    A["活动 / 渠道"] --> B["分享记录"]
    B --> C["消息发送"]
    C --> D["送达回执"]
    D --> E["打开短链"]
    E --> F["页面访问"]
    F --> G["内容行为"]
    G --> H["回复 / 预约意向"]
    H --> I["预约确认"]
    I --> J["实际到访"]
    J --> K["认购 / 签约权威结果"]
    B -. 规则版本 .-> L["归因计算"]
    K --> L
    M["活动成本"] --> N["ROI计算"]
    L --> N
    K --> N
```

每个事件至少携带租户、项目、客户或匿名身份、分享记录、内容版本、渠道、发生时间和来源系统。

### 10.3 渠道归因

第一阶段使用可解释规则：
- 首次有效触达；
- 末次有效触达；
- 指定时间窗内的线性多触点，仅在数据足够后开放。

系统保存全部原始触点和规则版本。Codex/Agent 可以选择已经批准的归因规则并解释结果，但不能临时发明口径。

### 10.4 ROI

只有同时具备以下条件，才能上线正式 ROI：
1. 渠道与活动标识稳定；
2. 广告和活动成本可获得；
3. 预约、到访、成交及金额来自权威系统；
4. 币种、税、周期、归属项目和取消/退款规则明确；
5. 归因规则版本化；
6. 缺失数据能够被识别而不是默认为零。

推荐分三层显示：
- 数据完整率；
- 漏斗转化与单位成本；
- 按批准口径计算的收入、利润或业务价值 ROI。

### 10.5 自动意向评分

实施顺序：
```mermaid
flowchart LR
    A["客观行为信号"] --> B["人员确认的客户条件"]
    B --> C["权威预约 / 到访结果"]
    C --> D["可解释规则评分"]
    D --> E["与真实结果校准"]
    E --> F{"质量是否稳定"}
    F -->|否| G["修正规则和数据"]
    G --> D
    F -->|是且确有增益| H["评估专用评分模型"]
    H --> I["显示证据、版本、衰减和纠正入口"]
```

评分输出必须包含：分值、等级、主要正负证据、规则/模型版本、置信度、衰减时间和人工纠正入口。评分不能成为拒绝服务、改变价格或自动作出重大业务决定的唯一依据。

---

## 11—19. 技术方案已拆分

业务主文档不再展开数据对象、Agent 工具、多租户架构、模型供应商、外部集成、服务器和安全实现。相关内容完整保留在 [《VISTA Link AI 智能体技术架构与实施方案》](./VISTA_Link_AI智能体技术架构与实施方案.md)。

为保持与原综合稿以及项目内既有引用一致，技术文档继续沿用原 §11—§19 编号；本业务主文档的后续章节继续从 §20 编号。

---

## 20\. 分阶段实施路线

各阶段不是并列功能清单，而是有明确依赖关系：
```mermaid
flowchart LR
    P0["阶段0<br/>数据、权限、版本和行为可信"] --> P1["阶段1<br/>七类正式销售场景连续可用<br/>并接入浏览器AI"]
    P1 --> P2["阶段2<br/>SMS单客确认发送"]
    P1 --> P3["阶段3<br/>预约与权威结果连接"]
    P2 --> P4["阶段4<br/>分享记录与渠道归因"]
    P3 --> P4
    P4 --> P5["阶段5<br/>ROI与可解释评分"]
    P5 --> P6["阶段6<br/>更多渠道与规则内自动化"]

    Q0["基础未可信"] -. 禁止开放 .-> Q1["自动对外执行"]
    Q2["没有权威结果"] -. 无法可靠建设 .-> Q3["ROI与评分"]
```

### 阶段 0：数据与基础产品可信

目标：AI 读取到的对象、版本、权限和行为必须可靠。
- 验证项目数据隔离；
- 统一页面数、启用链接数和统计口径；
- 修复客户专属链接、深层链接和会话恢复；
- 统一角色叠加和页面操作权限；
- 明确客户删除、匿名化和恢复规则；
- 建立页面/素材版本与引用影响；
- 统一外部自主浏览和现场演示事件来源。

未通过该阶段，不开放自动对外执行。

### 阶段 1：七类正式销售场景与浏览器 AI

目标：先让主 PRD 和 AI PRD 定义的七类场景能够连续运行，再完成“读—理解—草稿—证据—确认—保存”的 AI 子闭环。
- 项目能够维护通用及主要客群标准方案、主题内容包、标准提问、必讲项和风险项；
- 首次咨询和首次接待能够直接选择客群标准方案，不生成接待前个体方案；
- 已有客户现场讲解能够正确记录并进入客户追踪；
- 现场能够切换客群方案或快速追加、跳过内容，并保存实际变化；
- 客户产生明确反馈或有效行为，并由销售确认进入个体追客后，能够生成个体跟进和复访方案；
- 临时讲解能够在结束后关联、纠错或标记无效；
- 远程咨询能够查找/创建客户、选择或制作页面并取得访问地址；
- 到访后能够基于销售确认的反馈准备下一份页面；
- 客户自主访问后能够生成带依据的再次询问和资料建议；
- 购买申请和合同结果能够在外部完成后手动回写客户状态；
- 全局 AI 入口能够生成客户摘要、接待卡、纪要和页面工作草稿；
- 所有 AI 结果提供三层证据、确认、修改、驳回和审计；
- 多租户 Agent Gateway、任务中心和策略网关通过小范围功能开关试点。

### 阶段 2：SMS 单客行动闭环

目标：把 AI 建议变成一次可控制、可追踪的真实行动。
- 先完成 PRD 变更；
- 通信同意和退订；
- 日文 SMS 草稿；
- 单客户逐次确认发送；
- 短链、送达、失败、点击和访问回流；
- 频率、静默时段、防重复和人工接管。

### 阶段 3：预约与必要结果连接

目标：从“客户点击”连接到“权威业务结果”。
- 预约/日历系统接入；
- 暂占、确认、取消、改期和冲突处理；
- 实际到访结果回传；
- CRM 客户、负责人和必要阶段同步；
- 统一时间线和同步异常处理。

### 阶段 4：分享记录与归因

目标：回答“哪次内容、哪个渠道和哪个动作带来了结果”。
- 分享记录；
- 渠道和活动字典；
- 统一身份与事件链；
- 首次/末次触达；
- 渠道和活动漏斗；
- 数据完整率。

### 阶段 5：ROI 和可解释评分

目标：在有真实成本和结果后进行稳定测量。
- 成本和金额数据接入；
- ROI 公式与版本；
- 可解释规则评分；
- 与预约、到访和成交结果校准；
- 人工纠正和模型评测；
- 审批后的小范围规则自动化。

### 阶段 6：更多渠道和受控自动化
- LINE、邮件等连接器；
- 低风险、预授权的自动发送；
- 多触点归因；
- 企业专属策略和模型；
- 必要时为外部 Agent 提供标准 MCP/函数工具。

---

## 21\. MVP 分层定义

上一版把“首个 MVP”直接定义为客户浏览后的 SMS 行动，跳过了正式 PRD 本身的销售服务连续性。修订后采用两层 MVP，先证明业务主链能走通，再证明系统内行动能够闭环。

### 21.1 MVP-0：正式业务连续性验证

目标：使用一个已有客户、一个临时客户和一个远程咨询客户，连续覆盖主 PRD §7.1.1 的五个验收场景，并映射 AI PRD 的七类工作。

必须覆盖：
1. 项目至少配置一个通用方案和 4—5 个主要客群标准方案；
2. 首次咨询或首次到访能够选择客群标准方案，无法判断时使用通用方案，不生成接待前个体方案；
3. 现场讲解能够切换客群方案、追加或跳过内容并保存实际变化；
4. 离场后由销售确认客户明确反馈、未解决问题、下一步意愿和是否进入个体追客；
5. 客户进入个体追客后，AI 才根据可靠事实生成个体跟进、页面或复访方案；未商谈化客户继续使用标准培育；
6. 临时客户先讲解，后创建/选择客户并关联，包含一次关联纠错或无效记录处理；
7. 根据现场反馈或远程咨询选择/制作页面、发布并取得客户访问地址；
8. 明确验证“复制地址不等于实际发送，未打开不产生访问记录”；
9. 客户在独立浏览器中完成身份识别和自主访问；
10. 现场讲解与自主访问在客户追踪中并列但不合并；
11. 销售根据可靠访问再次准备页面，旧页面版本和旧访问明细不被覆盖；
12. 外部完成购买申请或合同后，销售依据明确结果手动更新为中间状态、签约或未签约；
13. 页面、讲解和浏览行为不能自动修改客户状态；
14. 全过程遵守租户、项目、角色、版本和审计规则。

### 21.2 MVP-1：AI 与 SMS 行动扩展

在 MVP-0 通过后，选择一个高频场景验证：
> **客户再次浏览或现场接待结束后，AI 根据可靠依据准备下一份页面和日文 SMS；销售确认后由 Link 发送；系统记录受理、送达、失败、点击和再次访问，再回到下一轮推荐或接待准备。**   

必须具备：
1. AI 结论显示依据、来源和资料版本；
2. AI 只生成草稿，不直接发送；
3. 销售能编辑、确认或驳回；
4. 通信同意、退订、频率和静默时段有效；
5. 消息、客户、页面版本、短链、渠道和确认人绑定；
6. 受理、送达、失败、点击和访问进入时间线；
7. 重复点击确认不会重复发送；
8. AI 或 SMS 不可用时，销售仍能取得访问地址并使用外部通道完成基本工作。

### 21.3 两层 MVP 都明确不做
- 群发营销平台；
- 完整销售任务系统；
- 预约、贷款、合同和交易流程；
- 正式 ROI；
- 黑箱成交概率；
- C 端开放式 AI 聊天；
- 无边界自动执行。

---

## 22\. 验收指标

### 22.1 产品与操作

| 指标 | 建议目标 |
|------|------------|
| 常规高频操作 | 不超过 3 次主要点击 |
| 确认一次 AI 草稿 | 不超过 30 秒，复杂内容除外 |
| 客户基础信息重复填写 | 0 次 |
| AI 重要结论可查看依据 | 100% |
| 可从依据跳到原始记录 | 100% |
| 事实、判断、建议区分 | 100% |

### 22.2 AI 质量
- 首次接触使用预设客群方案的覆盖率；
- 无足够依据时正确回退通用方案的比例；
- 客户进入个体追客后个体方案的采纳率；
- 接待准备草稿采纳率；
- 用户平均修改幅度；
- 关键条件提取准确率；
- 过期资料引用率；
- 无证据结论率；
- AI 被纠正的原因分布；
- 相同输入在模型切换后的结构一致性。

### 22.3 行动与业务
- 七类销售场景连续通过率；
- 首次接触使用客群标准方案的比例；
- 客群标准方案与现场实际展示差异的可追溯率；
- 离场后在规定时间内完成事实确认、下一步确认并进入个体追客的比例；
- 临时讲解在规定时间内完成关联、纠错或无效处理的比例；
- 复制访问地址与实际发送事件的区分准确率；
- 现场讲解与客户自主访问混记率必须为 0；
- 到访后页面准备完成率和从接待结束到可发送页面的时间；
- 客户自主访问后再次推荐的采纳率；
- 客户状态变更具有明确人工或权威外部依据的比例；
- SMS 发送成功、送达、失败和退订率；
- 重复发送率必须为 0；
- 短链点击与后续有效访问率；
- 预约意向到权威确认的转化；
- 未解决问题关闭率；
- 再次来访时准备卡使用率；
- 归因数据完整率；
- ROI 可计算记录覆盖率。

### 22.4 系统
- 跨租户/跨项目泄露为 0；
- 越权工具调用成功为 0；
- 浏览器刷新后的任务恢复率；
- 队列等待时间 P50/P95；
- 模型与连接器失败降级率；
- 每租户、功能和模型的成本可追踪率 100%。

---

## 23\. PRD 变更清单

正式 PRD 已有七类销售场景，但对象和扩展结果仍需要进一步落到可开发规则。在 SMS、预约、归因、ROI 和评分进入研发前，至少补充：
1. 将七类销售场景与五个连续验收场景建立固定映射，避免设计和测试各用一套流程；
2. 明确已有客户、临时客户和远程咨询三个入口及允许的客户建档时点；
3. 明确临时讲解的未关联、关联、关联纠错和无效状态；
4. 明确地址复制、二维码展示、页面与客户关联、外部实际发送和 Link 原生发送是五种不同事件；
5. 自主浏览与现场演示的来源字段、统计口径和并列时间线；
6. 项目级客群标准方案、通用方案、主题内容包、标准提问、必讲项、风险项、维护权限和版本规则；
7. 反响、初次接触、个体追客、申请及结果四阶段，标准培育与个体追客的边界，以及个体方案的数据模型和审计；
8. 客户条件、条件历史、接待准备快照、接待场次、客户反馈和未解决问题等对象；
9. 购买申请与合同结果的外部来源、人工确认、客户状态回写和禁止推断规则；
10. 分享记录、渠道、活动和实际发送事件；
11. 通信同意、退订、频率和静默时段；
12. SMS 草稿、确认、发送和回执状态机；
13. 预约意向、暂占、确认、取消、到访状态机；
14. 外部系统的主数据、同步方向和冲突规则；
15. 归因事件链、时间窗和规则版本；
16. ROI 成本、金额、币种、周期和公式口径；
17. 评分特征、解释、衰减、校准和纠正；
18. 工具风险级别、确认规则和预授权范围；
19. 多租户、项目、对象级权限；
20. 审计、保留、删除和合规规则；
21. 各阶段验收指标和明确不做范围。

---

## 24\. 开发前必须确认的业务决策
1. 是否正式采用“七类销售工作、五个连续验收场景、三个业务入口”的统一口径；
2. 是否采用“反响标准培育 → 首次接触使用客群方案 → 现场适配 → 离场确认 → 个体追客后个性化”的机制；
3. 第一批客群方案采用哪些需求导向分类，由营销企划、销售经理还是内容运营维护；
4. 哪些可靠事实和销售确认条件构成“进入个体追客”，仅有自主浏览时是否只提示复核；
5. 哪些内容属于不可删除的必讲项，哪些价格、贷款、交付和合同信息必须转交专业人员；
6. MVP-0 是否先于 Link 原生 SMS 上线并完成企业试用验收；
7. 首个试点项目、真实用户规模，以及已有/临时/远程三类样本各准备多少；
8. 当前正式范围中的外部发送工具需要记录到什么程度，谁负责确认“实际已发送”；
9. 第一系统内发送渠道是否确定为 SMS，供应商是谁；
10. 日本市场通信同意、退订和静默时段规则；
11. 客户、负责人、预约、到访、成交和金额各自的权威系统；
12. Link 是保存业务结果副本，还是仅保存外部引用；
13. 当前项目允许的 AI 数据范围；
14. 高风险信息的审核人和替代人员；
15. 哪些动作首期逐次确认，哪些未来可以预授权；
16. 分享渠道和活动字典由谁维护；
17. ROI 采用收入、毛利还是其他业务价值口径；
18. 评分的用途是排序、提醒还是自动触发；
19. 企业客户是否需要自带模型 Key 或专属部署。

---

## 25\. 日本市场与竞品参考链接

### 25.1 日本竞品企业
- KASIKA：[Cocolive](https://cocolive.co.jp/)、[主要功能](https://cocolive.co.jp/key-features/)、[2026—2027 路线图](https://prtimes.jp/main/html/rd/p/000000056.000025942.html)、[AI 推荐](https://prtimes.jp/main/html/rd/p/000000049.000025942.html)、[客户 MyPage](https://prtimes.jp/main/html/rd/p/000000051.000025942.html)
- ROOV：[STYLE PORT](https://styleport.co.jp/)、[新建公寓方案](https://styleport.co.jp/roov/for-mansion/)
- Digima：[企业信息](https://digima.com/company)、[产品官网](https://digima.com/)、[AI Agent 发布](https://prtimes.jp/main/html/rd/p/000000008.000002312.html)
- Facilo：[企业信息](https://www.facilo.jp/company/)、[产品官网](https://www.facilo.jp/)
- ITANDI：[企业官网](https://corp.itandi.co.jp/)、[服务动态](https://service.itandi.co.jp/news/260714)
- Musubell：[产品官网](https://www.musubell.com/)、[新建公寓方案](https://www.musubell.com/new-const/)
- いえらぶ：[集团](https://www.ielove-group.jp/)、[いえらぶ CLOUD](https://ielove-cloud.jp/service/)
- いい生活：[企业信息](https://www.e-seikatsu.info/aboutUs/profile.html)、[AI-native 平台 IR](https://www2.jpx.co.jp/disc/37960/140120260514532650.pdf)
- LIFULL：[企业信息](https://lifull.com/company/about/)、[LIFULL AI](https://lifull.com/news/45744/)

OpenAI、DeepSeek API、DeepSeek Harness、模型路由和数据安全等技术参考已经完整移入[《VISTA Link AI 智能体技术架构与实施方案》](./VISTA_Link_AI智能体技术架构与实施方案.md) §15—§19，本业务主文档不再重复列出。

---

## 26\. 最终建议

本项目不应在“只做内容链接”和“一次性建设完整 AI CRM”之间二选一。最合理的路径是：
1. **以正式 PRD 为底座**，先保证内容、页面、客户、权限、版本和访问行为可信；
2. **先建设房地产销售的客群标准方案**，按主要购房需求准备通用及 4—5 个客群内容路径，不让首次接待从零准备；
3. **反响和首次接触不做个体 AI 定制**：资料请求/登记后可以使用标准培育，销售首次接触直接选择客群标准方案，现场按真实反馈适配；离场后由销售确认进入个体追客，AI 才生成个体跟进与复访方案；
4. **采用日本销售场景文档的服务连续性设计**，让 AI 围绕接待前、接待后和信息变化工作；
5. **采用轻量化方案的交互原则**，把 AI 放进现有客户、页面和任务流程，不增加大量菜单和表单；
6. **采用 SMS 行动方案作为第一个执行扩展**，但必须先修改 PRD，并从单客、人工确认开始；
7. **采用四项薄弱能力文档的建设依赖**：先有动作与结果，再有归因，最后才有 ROI 和评分；
8. **采用竞品报告的防守策略**，守住专业内容、客户空间、行为语义和可确认 AI 草稿，把 CRM 与交易能力通过接口连接；
9. **采用浏览器多租户技术方案**，让 Agent 只通过强类型工具受控执行，绝不直接写数据库；
10. **拒绝当前阶段的重型扩张**：完整 CRM、完整交易、黑箱成交概率、开放式 C 端 AI 和无边界自动发送。

最终形成的产品闭环应当是：
> **项目先维护客群标准方案和专业内容 → 资料请求/登记客户接受标准培育 → 首次接触直接使用标准方案 → 销售现场适配并在离场后确认下一步 → 进入个体追客后 AI 生成跟进/复访方案 → 新行为与权威结果持续更新个体方案。**